Lecture 10_ Web attacks.md (6270B)
1 +++ 2 title = "Lecture 10: Web attacks" 3 +++ 4 5 # Web attacks 6 ## Authentication 7 Which is the best way to auth web users? 8 - IP address based: IP source can be spoofed, NAT can cause multiple users to have same IP, same user can have different IP (e.g. because of DHCP renewals) 9 - HTTP-based: hard to scale and manage at app level 10 - Cert-based: works for SSL-based, but few users have real certificates or know how to use them 11 - Form-based: form data might be sent as cleartext 12 13 Basic auth: 14 - form used to send username and password over SSL channel to server-side app 15 - the app: 16 - verifies credentials (e.g. by checking database) 17 - generates session authenticator, sends it back to user as part of header 18 - next time browser contacts same server, includes authenticator 19 - better auth: generate random value, store with other session info in file or backend db 20 - if app includes authenticator in URL, browsers may leak info as part of "Referer" field (which btw can also be spoofed for attacks if used for auth) 21 - authenticators shouldn't be long lived 22 23 Attacking authentication 24 - eavesdropping credentials/authenticators 25 - if HTTP connection not protected by SSL, can be eavesdropped 26 - name and pass sent as part of HTTP basic auth exchange 27 - auth included as cookie, URL param, or hidden field in form 28 - setting 'secure' flag on cookie is good way to prevent accidental info leaking 29 - bruteforce or guess credentials/authenticators 30 - if authenticators have limited value domain (like 4 digits), can be bruteforced 31 - if chosen in non-random way, can be easily guessed (sequential session ID, user-specified password) 32 - bypass authentication (session fixation, SQL injection) 33 - weak pass recovery procedures can be leveraged to reset password to known value 34 - session fixation forces user's session ID to known value (e.g. by passing session ID in URL) 35 36 ## Authorization 37 Authorization: what can a user do? 38 39 attacks: 40 - path/dir traversal attacks: break out of document space with relative paths (`GET /show.php?file=../../../etc/passwd`) 41 - forceful browsing: 42 - web app dev assumes application will be accessed through links 43 - user is not bound to follow prescribed links, can jump to any publicly available resource 44 - automatic directory listing abuse: browser may return listing of directory if there's no index 45 - parameter manipulation 46 - resources accessible are determined by params to query 47 - if client-side info blindly accepted, one can modify parameter to get more information 48 - parameter creation 49 - if params from command line blindly imported, one might modify behavior of application (like adding `&admin=1` to the end) 50 - PHP `register_globals` 51 - makes request info (GET/POST vars and cookies) available as globals 52 - vars can be provided so that unexpected execution paths are followed 53 - vars could be set regardless of condition checks 54 - all vars should be initialized/sanitized along every path 55 - check `php.ini` or `.htaccess` to make sure of its state 56 - server misconfiguration 57 - FTP and web sometimes run on same host 58 - if data can be uploaded with FTP and requested with Web server, you can run programs using CGI and run commands using Server-Side Include 59 60 ## Command Injection attacks 61 Main problem: 62 - wrong or no validation of user input that lets you run commands on the server 63 - use of unsanitized input to compose strings passed to function that can eval code or include code from a file 64 65 Server-side includes (SSI) 66 - simple interpreted server-side scripting language 67 - lets you introduce directives into web pages as `<!-- #element attribute=value attr2=val2 ... -->`, run when included 68 - can use `exec`! so a user can run any command. for example, by adding directive `<!-- #exec cmd="cat /etc/passwd" -->` 69 70 PHP's `allow_url_fopen` allows URLs when including files with `include()`/`require()`, if user input used for this then bad 71 72 HTML injection: 73 - injection of HTML tags can be used to change behavior of web page 74 - with iframe tags, browser forced to access malicious web page 75 76 How do you survive? Don't trust user input, use built-in sanitization functions. 77 78 ## SQL injection 79 Input validation error where SQL queries built using unsanitized parameters provided by users. 80 81 For example, if logins are verified by checking with a database like this: 82 83 ```asp 84 var sql = "select * from user_accounts \ 85 where username = '" + username + "' and \ 86 password = '" + password + "'"; 87 ``` 88 89 If you enter `' or 1=1 --` as the username, you get this query, returning the whole table: 90 91 ```sql 92 select * from user_accounts where username='' or 1=1 --' and password=" 93 ``` 94 95 SQL injection can modify any type of query (SELECT, INSERT, UPDATE, DELETE) 96 97 With MySQL, double-dash comment requires the second dash to be followed by at least one whitespace/control character. 98 You can use subqueries to get more info, e.g. `(select version())` as one of the fields in an INSERT query. 99 If results aren't seen immediately, see if they are reflected somewhere else on the page. 100 101 Number of columns in query can be determined by using `UNION SELECT NULL`, `UNION SELECT NULL, NULL`, etc. progressively longer. 102 Type of columns can be determined by adding e.g. a string to the `UNION SELECT`. 103 104 To determine table/column names, rely on database-specific techniques. 105 Want to look at metadata tables, schema tables, etc. 106 107 Second Order SQL injection 108 - SQL code injected into app, but statement invoked at later time 109 - even if app escapes single quote, second order may be possible 110 - attacker sets username to `john'-`, app escapes value to `john''-` 111 - at later point, attacker changes pass and sets a new pass for victim John, creating new SQL command with unsanitized data 112 113 Blind SQL injection (when no output/error from web app) 114 - prohibiting display of error messages is typical countermeasure, but blind injection might still work 115 - when looking for vulnerability, 1=1 is always true. so similarly, use AND statement to check if other properties are true. 116 117 Dealing with SQL injections 118 - don't let client-supplied data modify SQL statements 119 - stored procedures: isolate apps from SQL, put the statements on the database server 120 - prepared statements: compiled before user input is added